FIG. 1 is a schematic diagram of a network-based mobility management system. The network-based mobility management system shown in FIG. 1 includes a mobility anchor 100, an access gateway (access GW) 200, and a mobile terminal 400. In the network-based mobility management system, a node disposed in a network 10, such as the access GW 200, performs mobility management for the mobile terminal 400 in behalf of the mobile terminal 400. In contrast to this, a mobile communication system in which the mobile terminal 400 itself takes part in the mobility management for the mobile terminal 400 is called “host-based mobility management system”. An example of the network-based mobility management system is a system adopting PMIPv6 (Proxy Mobile IPv6). Meanwhile, an example of the host based mobility management system is a system adopting MIPv6 (Mobile IPv6). In this specification, the term “mobility management system” means the network-based mobility management system unless otherwise specified.
As shown in FIG. 1, the mobility anchor 100, the access GW 200, and a mobility management node 300 are disposed in the network 10. A corresponding node (CN) 500 disposed in an external network 20 is an apparatus that performs data communication with the mobile terminal 400. The CN 500 provides service through a network, such as WEB service, to the mobile terminal 400. The CN 500 is not included in the mobility management system and does not take part in the mobility management.
In the mobility management system shown in FIG. 1, the access GW 200 registers, into the mobility anchor 100, a terminal identifier of the mobile terminal 400 and information of the access GW 200 that is used as a transfer destination of data packets addressed to the mobile terminal 400. The mobility anchor 100 transfers the data packets, sent from the CN 500 and addressed to the mobile terminal 400, to the access GW 200 to which the mobile terminal 400 belongs (i.e., the movement destination of the mobile terminal 400) by using the registration of the association between the terminal identifier and the access GW information (which is hereinafter called “position registration”). In this way, even when the mobile terminal 400 moves between access GWs 200, the mobile terminal 400 can communicate continuously. An address of the mobile terminal 400 is, for example, used as the terminal identifier of the mobile terminal 400. An address of the access GW 200 is, for example, used as the information of the access GW 200 which is the transfer destination of data packets. Further, a tunneling technique is, for example, used for transferring data packets between the mobility anchor 100 and the access GW 200.
In the mobility management system shown in FIG. 1, PMIPv4 (Proxy Mobile Internet Protocol version 4) or PMIPv6 (Proxy Mobile Internet Protocol version 6) standardized in IETF (Internet Engineering Task Force) is, for example, used as a protocol for implementing the position registration of the mobile terminal 400. Alternatively, other protocols such as GTP (General Packet Radio Service (GPRS) Tunnelling Protocol) standardized in 3GPP (Third Generation Partnership Project) can be used. With regard to PMIPv4, PMIPv6 and GTP, please refer to Non-patent literatures 1, 2, and 3 respectively. Basically, all of these mobility management protocols specify operations in accordance with the above-described mobility management method, though they have some differences in terms of signal formats, information included in signals, and tunneling scheme for transferring data packets. Examples of mobile communication systems to which these mobility management protocols are applied include GPRS and EPS (Evolved Packet System) standardized in 3GPP. Further, the above-described mobility management protocols are also applied to mobile communication systems standardized in 3GPP2, WiMAX Forum, and so on.
For example, in EPS, the mobility anchor 100 and the access GW 200 correspond to P-GW (Packet Data Network (PDN) Gateway) and S-GW (Serving Gateway) respectively. In GPRS, the mobility anchor 100 and the access GW 200 correspond to GGSN (Gateway GPRS Support Node) and SGSN (Serving GPRS Support Node) respectively. Further, in PMIPv6, the mobility anchor 100 and the access GW 200 correspond to LMA (Local Mobility Anchor) and MAG (Mobile Access Gateway) respectively. Note that LMA and MAG in PMIPv6 mean functions on the protocol, and do not mean node names on actual communication systems.
The mobility management node 300 performs the mobility management for the mobile terminal 400 by controlling the access GW 200 in response to a request issued from the mobile terminal 400, one of the nodes on the network 10, or an apparatus having an O&M (Operation & Management) function. Specifically, the mobility management node 300 controls the access GW 200 to send signals for mobility management to the mobility anchor 100. Depending on the system, the mobility management node 300 may not be an independent node. That is, a function equivalent to the mobility management node 300 may be included, for example, in the access GW 200. In the case of EPS, the mobility management node 300 is defined as an independent node called “MME (Mobility Management Entity)”. In contrast to this, in the case of GPRS, which is also in 3GPP, the function of the mobility management node 300 is incorporated into SGSN.
What is explained above is the configuration and the operation of a conventional network-based mobility management system. Here, consider a case where the mobility anchor 100 that is providing anchor service for mobile communication of the mobile terminal 400 is switched to another mobility anchor while continuing the communication of the mobile terminal 400. Detecting an abnormality in the mobility anchor 100, or performing load balancing may be used as a trigger for switching the mobility anchor 100. However, at the present moment, there is no technique for switching the mobility anchor while continuing the mobile communication in the actual systems such as 3GPP systems. In NETEXT (Network-based Mobility Extension) WG of IETF, a proposal for achieving this object in PMIPv6 has been made (see Non-patent literature 4).
Non-patent literature 4 discloses two different methods for switching the mobility anchor 100. These switching methods are briefly explained hereinafter with reference to FIGS. 2 and 3. In FIG. 2, the access GW 200 accommodating the mobile terminal 400 sends a position-registration-request signal to a mobility anchor 100A in response to a trigger of some kind (step S101). Examples of the trigger for sending a position-registration-request signal include a situation that the mobile terminal 400 connects, and a situation that a position registration has been already made for the mobility anchor 100A and the expiration time of that position registration is approaching. The position registration request includes the addresses of the mobile terminal 400 and the access GW 200. That is, by sending the position registration request, the access GW 200 requests the mobility anchor 100A to transfer data packets addressed to the mobile terminal 400 to the access GW 200.
In response to receiving the position registration request, the mobility anchor 100A performs a message exchange (signaling) with a mobility anchor 100B that substitutes for the mobility anchor 100A. In this way, the target mobility anchor 100B possesses position registration information to transfer data packets addressed to the mobile terminal 400 (step S102). After that, the mobility anchor 100A sends a position-registration-response signal containing the address of the mobility anchor 100B to the access GW 200 (step S103). By using the address of the mobility anchor 100B stored in the position-registration-response signal received from the mobility anchor 100A, the access GW 200 sets up a tunnel, which is used to transfer data packets transmitted/received from/by the mobile terminal 400, between the access GW 200 and the mobility anchor 100B (step S104). As a result, data packets transmitted/received from/by the mobile terminal 400 are transferred through the tunnel newly established between the access GW 200 and the mobility anchor 100B.
Another method for switching the mobility anchor 100 is explained with reference to FIG. 3. In the procedure shown in FIG. 3, a process for a position-registration-request signal in a step S201 is substantially same as the processes for the position registration request (step S101) and the position registration response (step S103) shown in FIG. 2. However, in the procedure shown in FIG. 3, without performing the information exchange between the mobility anchors in the step S102, the access GW 200 performs the position registration process with the mobility anchor 100B by using the address of the mobility anchor 100B contained in the position-registration-response signal (S202). After that, data packets transmitted/received from/by the mobile terminal 400 are transferred through the mobility anchor 100B in a similar manner to that in the step S104 in FIG. 2. The access GW 200 determines which of the operations shown in FIGS. 2 and 3 should be performed according to a response code that is contained, together with the address of the substitute mobility anchor 100B, in the position-registration-response signal from the mobility anchor 100A.
In the case of PMIPv6, for example, the position-registration-request signal and the position-registration-response signal described above with reference to FIGS. 2 and 3 correspond to “Proxy Binding Update” and “Proxy Binding Acknowledgement” respectively. Further, in the case of 3GPP EPS, for example, the position-registration-request signal corresponds to a default bearer establishment request message that is transmitted from S-GW to P-GW and the position registration response signal corresponds to a bearer establishment response message that is transmitted from P-GW to S-GW.